home *** CD-ROM | disk | FTP | other *** search
- Path: news2.acs.oakland.edu!news
- From: bradw@exptech.com (Brad Wilson)
- Newsgroups: comp.graphics.algorithms,comp.lang.c++,comp.os.ms-windows.programmer.graphics,comp.os.ms-windows.programmer.multimedia,comp.os.ms-windows.programmer.win32
- Subject: Re: IJG JPEG Engine and Win32
- Date: Tue, 23 Jan 1996 17:05:31 GMT
- Organization: Express Technologies Corp.
- Message-ID: <4e34f7$40e@news2.acs.oakland.edu>
- References: <4cemir$6vb@redstone.interpath.net> <TGL.96Jan3202549@netcom21.netcom.com> <TGL.96Jan5065424@netcom21.netcom.com> <4cpn1r$gm0@redstone.interpath.net> <4crai5$ear@hades.rz.uni-sb.de> <4d11tg$56q@redstone.interpath.net> <310110c0.44581633@news.connectnet.com>
- NNTP-Posting-Host: ppp-pm01-dy-12.opr.oakland.edu
- X-Newsreader: Forte Free Agent 1.0.82
-
- jtara@connectnet.com (Jon Tara) wrote:
-
- >> > Incidently, malloc() and free() are measureably slower under
- >> >Windows 95. These generate calls to GlobalAlloc which are still in the
- >> >Win32 API just for compatability. Under Win32 you want to use HeapAlloc
- >> >or VirtualAlloc if you can.
-
- >> I'm not sure that using VirtualAlloc() would be such a good idea,
- >> except for large blocks. malloc() and free() grab large blocks and
- >> then divvy them up, so most of the time when you call malloc() it
- >> doesn't actually go out to the operating system and allocate anything.
-
- This was true in Visual C++ until 4.0. Now _all_ memory allocation
- calls are turned into native calls to the operating system.
-
- Brad
-
-
-